Nature of the problem—Achieving efficient and transactional messaging between client and server applications over multiple intermittent networks.
Client-Server is an architecture that has long been in use within computing. It became popular with the advent with the Personal Computer (PC), which was used to access data on a central server. The simplest case of this is the File Server configuration where a set of files is stored on the server and accessed by the PC. Novell Netware and Sun's Network File System (NFS) are examples of technologies that were used to share files. Another popular client-server configuration is to have a thick-client application on the PC accessing a database on the server using standards such as Structured Query Language (SQL) and Open Database Connectivity (ODBC).
Tightly coupled client-server architectures indicate that the client requires access to the server to get information. If the server is not available, the client is essentially useless. Much of the client-server computing in use today is tightly coupled. The web browser is an example of a tightly coupled client-server model because it retrieves HTML from web servers. Without access to web servers, there is little that a browser can do.
Loosely coupled clients are independent of the server and access the server only when needed, such as to access or update information. Mail clients like Microsoft Outlook is a good example, where one can read and write emails while not connected to a mail server.
Most client-server computing has been deployed in a Local Area Network (LAN) or other always-on networks, eg. leased lines, dial-up. Therefore, it is not difficult to achieve a high level of reliability. There has not been a compelling need to introduce middleware to improve the reliability. Even so, applications that require transactional-level guarantees will use some kind of Transaction Processing middleware to track, audit and roll back transactions.
In addition, the assumption within a LAN is that there is only one network and that the cost of using it is essentially free. There has not been a requirement to choose among the use of multiple networks. Nor has there been a need to carefully consider the cost of using the network, eg. how many bytes are being sent or how long it is being used.
However, with the advent of wireless networks, this is all changed. Wireless networks are by their very nature intermittent since you are never guaranteed to have a clear signal. And often, there are places where there is no connection at all. Wireless carriers typically charge for usage of their network by the byte, so it becomes important how much bandwidth is being consumed. And there are multiple networks now available to computers, such as wire-line LAN, WiFi (IEEE 802.11b and successors), Wireless Wide Area Networks (GPRS, 1xRTT), Bluetooth and even a serial cable between a PDA cradle and a PC.
Another new issue raised by the use of mobile computers is the management of the devices and assets on those devices. In the current philosophy of network and system management embodied by software such as HP OpenView and CA Unicenter, there is an assumption that network elements or nodes (eg. computers, routers, switches) are always connected to the network and rarely move. It is therefore straightforward to manage the elements using Simple Network Management Protocol (SNMP) and deploy or update software on those stationary devices. However, with devices that are mobile, there is a new set of issues. These mobile devices are not always connected and if they are, they may be connected to multiple networks and therefore have multiple IP addresses. They might be shared among a group of users (eg. truck drivers who take any arbitrary handheld computer when the start their rounds). The devices must be secure but not impose a heavy price by slowing performance or sending exponentially larger packets on expensive wireless networks.
It is therefore plain that one cannot simply extend the current networking philosophy to computing on intermittent networks. In order to deploy usable and cost-effective client-server solutions that are mission-critical on intermittent networks, the goals should be transactional guarantee and manageability.
Transactional guarantee means that the system must keep functioning regardless of whether there is connectivity or not. No messages should ever be lost but they should be kept in reliable persistent storage at each step so that they can be recovered should a failure occur in the system such as a power outage. The entire system, consisting of the mobile devices and servers, must always be in a consistent state. Even when a failure occurs, the transaction should be rolled back or otherwise compensated so that there are no conflicts in any application. An example of this is when a transaction is to be committed to two applications; if one succeeds and the other fails, the one that succeeded should be rolled back so that they are both consistent. Only when both have succeeded should the transaction be committed. The system should be performant and not allow a fault to throttle the entire system, ie. cause it to stop working or go into an infinite loop and consume a lot of resources. This can happen when a message is in a queue that is fails to be committed to a target application and continues to retry constantly; this is called a “poison message” and should be immediately taken off the queue and processed differently. It should also be very resilient to faults such as badly formatted messages so that the system does not need to be restarted when responding to problems.
Manageability encompasses security, asset management, software deployment and cost control. Security covers the usual areas of authentication, authorization, encryption and non-repudiation. There are many existing technologies that can meet these requirements.
Mobile devices have additional requirement of remote locking when a device is reported lost or stolen. This can be done by sending a “poison pill” to kill the device and possibly destroy data or revoking the privilege to connect back to the server when it attempts to do so the next time a connection is available. Asset management refers to tracking the devices (eg. who owns it, where is it) and the management of the configurations on the device (eg. network settings, email settings). It is required that these are done set by a central system administrator and done automatically so that the user is not burdened to set up the configuration, which can be a complex and error prone process requiring much support. Another aspect of asset management is the ability to remotely run diagnostic test programs on the device. For example, the administrator might want to schedule the barcode scanner to be test every day and a report sent automatically when there is a connection so that he knows if the device needs to be brought into the office for maintenance. Software deployment is an area that has received a lot of attention because of the high cost of keeping the correct versions and license of software on computers. This problem is compounded for mobile devices that you cannot physically check. Software deployment configurations must be set up by the administrator remotely, whether the device is connected or not. When a device comes on line, it must automatically know which software to update. The administrator must also be able to specify which network to be used for software deployment. For example, use the free WiFi or serial connection to update software and only use the expensive wireless WAN for sending urgent application messages. Backing up data on the device is also a requirement for devices that have substantial disk storage such as laptops. Cost control is a new requirement for wireless devices where it does matter how much bandwidth is being used. Because wireless networks are more expensive, slower and intermittent, it becomes important for an application to determine which messages should be sent on which networks. Urgent and important messages should be sent on any available network. Less urgent and important messages should wait until a cheaper network is available. Other factors might come into play, such as system or network constraints. For example, if a satellite channel is available, only the most urgent and small messages might be sent. If the time is after 5 pm or the battery is low, perhaps the pending messages should be flushed immediately on any available channel.